-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/operator restrictions #4
base: feat/generic-sanity-checks
Are you sure you want to change the base?
Feat/operator restrictions #4
Conversation
Removed 'signature' member from 'Order' struct as it's essentially a message that users will sign. Having signature in the message makes the contract susceptible to signature malleability attacks.
…and define constructor
implemented vault contract to facilitate asset transfers between the maker and the vault.
integrated vault contract for asset transfers from the maker's address to the vault contract in AdvancedOrderEngine contract. Imported vault contract and invoked its _receiveAsset function for funds transfer
Added a validation check to ensure that maker receives an amount equal to or more than requested
…nt in vault-to-maker asset transfer
removed the 'facilitatorInteractionTargetContract' var from the 'fillOrders' fn param. Facilitator is now expected to provide the target contract address within the 'facilitatorInteractionCallData' param. Also removed the facilitator target contract address check
…fn param to 'facilitatorInteraction'
bytes32 public constant ORDER_TYPE_HASH = | ||
keccak256( | ||
"Order(" | ||
"uint256 nonce," |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use smaller datatype for nonce ?
@0xhammadghazi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'm considering this. Actually, we can consider using smaller types for the following variables: nonce, validTill, sellTokenAmount, buyTokenAmount, and feeAmounts
@@ -33,6 +31,13 @@ contract AdvancedOrderEngine is Vault, EIP712 { | |||
string memory version | |||
) EIP712(name, version) {} | |||
|
|||
modifier onlyOperator() { | |||
if (!isOperator[msg.sender]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xhammadghazi Refactor a modifier to call a local function instead of directly having the code in the modifier, saving bytecode size and thereby deployment cost Ref
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acknowledged. The bytecode of the function modifier is duplicated/copied to each method, but we are currently using onlyOperator in only one function. Therefore, it won't make any difference at the moment, but yes, it's a good point to consider during the gas optimization phase.
// STUB: PARTIAL FILL FEATURE // | ||
|
||
// TBD: debatable, can take signing scheme in order schema or can verify like 1inch | ||
if (order.isContract()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make seperate function for processing orders from contract or account like 1inch is doing , better for readibility..
https://github.com/1inch/limit-order-protocol/blob/master/contracts/OrderMixin.sol#L222C15-L222C15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I will take it into consideration.
} | ||
|
||
// STUB: VERIFY PREDICATES // | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xhammadghazi Will there be any more checks related to predicates ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure yet, I will work on the predicates section tomorrow, so only then can I tell.
isOperator[_address] = _access; | ||
|
||
emit OperatorAccessModified(_address, _access); | ||
} | ||
|
||
/** | ||
* @notice Fills multiple orders by processing the specified orders and clearing prices. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xhammadghazi
The natspec for signatures seems missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
acknowledged
@@ -34,30 +88,137 @@ contract AdvancedOrderEngine { | |||
} | |||
|
|||
// Revert if the length of the orders array does not match the clearing prices array. | |||
if (orders.length != clearingPrices.length) { | |||
revert ArraysLengthMismatch(orders.length, clearingPrices.length); | |||
if (orders.length != offeredAmounts.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xhammadghazi
do you think that we also check that signatures.length matches orders.length?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes indeed
According to this PR I've gone through the Slither report and here's what stands out:
Once we tackle these and any other points you spot in the PR, we should be good to merge! |
Stubs implemented: